home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 420 < prev    next >
Text File  |  1994-08-27  |  14KB  |  382 lines
  1. Subject: The Undigestable Digested
  2. Date: Sun, 12 Jun 1994 17:30:22 +0200 (MDT)
  3. From: Annius.Groenink@cwi.nl (Annius Groenink)
  4. X-Face: "E3Hm]k]&:,OEP<{D2ixJf>-9[qOGLebNa0&cQyFL-a~)kTM3&&I"gFw=fJ]K%1IduGjOE`
  5.  ZGu]&~G]QNGa7i/L!+#Xng<|+}HKYHj~5?fTInUEUh0$I1gBI7jrA!&_|e/pR1[cX:^xgJTPsrjA_9
  6.  m8Zli[|.-u{]+c1(6C7mL*m`/_J\>.{4!:g
  7. Mime-Version: 1.0
  8. Precedence: bulk
  9.  
  10.  
  11.  
  12. Neil:
  13.  
  14. > I think the ST Book had a blue 'Atari' key, which meant certain keys with blue
  15. > figures on could be used as a numeric keypad... I don't know wether they work
  16. > the same way or not, but it is laid out exactly the same...
  17.  
  18. Ah.  A nice way to represent the num pad key combinations (in blue) in menus.
  19.  
  20. -------
  21.  
  22. Warwick:
  23.  
  24. > A MUCH safer technique is to use Shift-FULLER.  It also trains users to
  25. > look on the right-hand side for the SMALLER.  It's also very meaningful,
  26. > since the FULLER already means `Change Size', which is what iconification
  27. > is all about.
  28.  
  29. Makes sense.  I'll change my code.  Should this be part of the standard?
  30.  
  31. -------
  32.  
  33. Proposal v5:
  34.  
  35. >CTRL Home -              Move to top of page
  36. >Shift+CTRL Home -        Move to bottom of page
  37. >ClrHome -                Move to top of document
  38. >Shift+ClrHome -          Move to bottom of document
  39.  
  40. More standard is
  41.  
  42.    Control Uparrow        Move to top of page
  43.    Control Dnarrow        Move to btm of page
  44.    Shift Uparrow          Page up
  45.    Shift Dnarrow          Page dn
  46.  
  47. ------
  48.  
  49. Michael Nolte proposes to add Ctrl to home/shift home for top/bottom of document:
  50.  
  51. > - Safety. If you accidentally press ClrHome, you'll find back to where you
  52. >   were easier, if the cursor has only jumped to the top of the frame/page 
  53. >  instead of jumping to the top of the document. CTRL-ClrHome is harder  
  54. > to hit by accident.
  55.  
  56. This is much the same story as Control A being dangerous---an application should
  57. provide a way to jump back to the original position when a user hits HOME by
  58. accident.  (for example by placing a marker).  It is not the code that is dangerous,
  59. but the limitated safety measures (no airbag) of most applications.
  60.  
  61. ------
  62.  
  63. Stefan:
  64.  
  65. > What about standard key for fulling a window?
  66. >  I use: *
  67. > And for zooming the window contents?
  68. >  I use:
  69. >  + for zoom in, more details
  70. >  - for zoom out, fewer details
  71. >  0 for original zoom factor
  72.  
  73. Yes.  Pretty standard!  I proposed this earlier.  It should at least be implemented
  74. optionally,  as I've done in Edith.  It applies to practically any GEM application.
  75. (In Edith +/- means smaller/larger font).
  76.  
  77. -----
  78.  
  79. Warwick on Redo/Repeat
  80.  
  81. > VI users would propose CTRL-.
  82.  
  83. (and so would the few who have already got used to Edith Pro...)  Seriously,  Undo
  84. and Redo have 'do' in common,  so I really think having Shift Undo or Control Undo
  85. as redo is nice.  But we argued earlier that redo and do again is not the same!
  86. Redo is un-undo,  whereas for 'do it again',  no undo operation needs to have occurred.
  87. 'Do it again' after Undo could mean 'Undo the operation BEFORE the one just undone.'
  88. (if an application has multi-stage undo).
  89.  
  90. -----
  91.  
  92. Michel in reply to my HELP philosophy
  93.  
  94. > Why strictly ASCII files?  The main advantage of using a program like
  95. > ST-Guide is that you can have images, diagrams, boxes, circles, text
  96. > effects, and other features to make your online help presentable.  Since
  97. > it is an external program, it also does not add to the size of your
  98. > application.
  99.  
  100. The reason I want plain ASCII files is that it is then very easy to drag
  101. all the documents on your hard disk into a directory.  Write a short description
  102. of each file,  call the file containing the descriptions WHATIS (cf. Unix man)
  103. and the thing works!
  104.  
  105. > Er, what?  I'm not sure I follow this point.  Is there any particular
  106. > reason why you would not want your data files in the same directory
  107. > as your program?
  108.  
  109. Well...  I recently divided my HD into applications,  resources and user-specific
  110. data.  Of course,  on a multi-user system,  this would always be the case.
  111. And yes,  I feel happier if all help files are in the same hierarchy,  apart from
  112. the applications.
  113.  
  114. -----
  115.  
  116. Michel:
  117.  
  118. > Ofir, I just noticed; there is no "abandon" key in the standard.  The
  119. > standard (used by all programs I have seen) is Control-H.  Since that
  120. > is not used in the proposal, could we add this key?
  121.  
  122. Control H was originally in a note saying:  Atari suggest control H for
  123. Replace (as in swap text block and selection fragmentwise).  This is a very
  124. good way of looking at search and replace.  It should remain available
  125. optionally.  And since we're talking about UNDO anyway,  what about:
  126.  
  127.    Undo        Undo
  128.    Sh Undo     Redo                 (shift being a modifier that sometimes
  129.                                      means `in the opposite direction')
  130.    Ctl Undo    Undo the whole lot   (i.e.  Abandon or Restore)
  131.  
  132. Ofir replies:
  133.  
  134. > There is, although I put it in the wrong place.
  135. > 
  136. > CTRL D -                 Abandon Window (iconify or place in menu)
  137. > 
  138. > as suggested by Wilfried Behne.
  139.  
  140. That's not the same kind of 'abandon'...
  141.  
  142.  
  143.  
  144. Michel [I was over-expounding on active/top windows...]
  145.  
  146. > Annius, I feel that this is too specific.  Making a distiction between
  147. > the top window and the active window only applies to Edith.  No other
  148. > program I have seen (ever) have made this distiction.  Making it a part
  149. > of the standard would be too complex, when we are trying to keep things
  150. > simple.
  151.  
  152. You're probably right.  I should find my own way of doing this within the
  153. standard as it is proposed.  However,  there are a few programs that support
  154. key input into background windows  (ASCREEN is one,  and I've got two other
  155. German goodies on my disk but I forgot which ones).
  156.  
  157. -----
  158.  
  159. Timothy ``my little finger'' Miller writes:
  160.  
  161. > The block=big-cursor method seems the most natural to me, and one of the 
  162. > reasons I like it is that the cursor commands are heterogenious, where 
  163. > the same commands that work on text work on blocks just the same, and 
  164. > another reason I like it is that it takes a lot fewer total keypresses to 
  165. > deal with
  166.  
  167. ...and a lot fewer total keypresses to unintentionally get rid of your documents!
  168.  
  169. -----
  170.  
  171. Warwick in the ``what should preceed what'' discussion:
  172.  
  173. > action:key:
  174. > 
  175. >     *Dialog*.Confirm.Key: Return
  176. >     *Dialog*.Confirm.Colour: Green
  177. > 
  178. > 
  179. > key:action:
  180. >     Dialog*Key.Return: Confirm
  181. >     Dialog*Colour.Green: Confirm
  182. >     # huh?
  183.  
  184. I'd say there are sections
  185.  
  186.    'key'       maps a key code to a value (an action)
  187.    'colour'    maps a user interface component to a value (a colour)
  188.  
  189. hence
  190.  
  191.          Dialog*Key.Return:      Confirm
  192.          Dialog*Colour.Confirm:  Green
  193.          # hm.
  194.  
  195. I think I'll stay low level for a while.  Things are getting ever more complicated...
  196. I think at this point,  reading the rest of Warwick's story,  I agree with
  197. 'action-key'.  My original thought was 'key-action' would be easier to implement
  198. (an array 'indexed' by the keys for quick access to their corresponding actions)
  199.  
  200. -----
  201.  
  202. Gerd:
  203.  
  204. > When we talk about text blocks, we should have in mind, that text blocks
  205. > can be discontinuous!
  206.  
  207. > In the case of block operations: Have discontinuous blocks in mind.
  208.  
  209. I am!  Actually,  I've got one in my window right now!
  210.  
  211. -----
  212.  
  213. Timothy 'Control-A' Miller replies to someone arguing about ShCtl S <-> Ctl M
  214. (it takes 10 minutes to get used to ShCtl S)
  215.  
  216. > Ah, but you use the opposite logic when saying why we should keep 
  217. > Ctrl-A.  If they'll take 10 minutes to get used to the new standard, then 
  218. > they'll take 10 minutes to learn something other than ctrl-a, and they 
  219. > won't be bothered by it since ctrl-a will do absolutely nothing.
  220.  
  221. I *actually* agree here!  Small sacrifice to swap ^A and Shift^A!
  222.  
  223. -----
  224.  
  225. Tim:
  226.  
  227. > But I've never seen a text editor (I haven't seen the one you mention) 
  228. > that did discontinuous blocks.  Sounds like it would be a pain to deal 
  229. > with... I'd need to keep track of ANOTHER linked-list in memory.  
  230. > <grumble>  Memory management....
  231.  
  232. Papyrus is a word  processor, not an editor.  Edith  (which I wrote  and
  233. ZFC distributes) is an Editor which does discontinuous blocks.  BTW,   I
  234. don't use a  linked list  at all,   I simply use  an array  and a  smart
  235. re-allocation  scheme.   But  I  agree,   discontinuous  blocks  is  not
  236.